The present invention relates generally to network security and more particularly to access control in a proxy server.
It is important to prevent unauthorized access to a server via an external network such as the Internet. It is also important to prevent unauthorized access to a server from an intranet. To address these problems, it was known to utilize a proxy server logically situated between the external network and the server, and between clients on an intranet and a server on the intranet. When a proxy server forwards an access request from an intranet it is functioning as a “forward proxy”. In such a case, the proxy server performs access control by checking an access control list to determine whether or not forwarding of the access request is permitted. When a proxy server forwards an access request from an external network, it is functioning as a “reverse proxy”. In such a case, the proxy server performs access control by checking an ACL to determine whether or not forwarding of the access request is permitted.
Various access control techniques using proxy servers currently exist such as access control based on Uniform Resource Locator (“URL”) (hereinafter referred to as URL-based access control). The URL is the address location of resources on a TCP/IP network such as the Internet or an intranet. IBM Tivoli Access Manager™ product is a known software product using URL-based access control. The following is an example of a computer system using the current IBM Tivoli Access Manager™ product. The system includes a proxy server, a client and a Web server. The proxy server is connected to the client by network connection through the Internet. The proxy server is connected to the Web server by network connection through an intranet, and has an ACL. An ACL, such as shown in FIG. 9, contain information necessary for determining which URLs are allowed to be access through the external network and/or which URLs are not allowed (i.e. prohibited) to be accessed through the external network. In ACL 107 shown as an example in FIG. 3, the URL “http://www.ibm.com/CustomApp?confidential” and the URL shown in FIG. 10 are entered as URLs to which access is not allowed (access-prohibited URL).
The access control is performed as follows. The proxy server receives an access request (for example, as an HTTP request) from a client. Then, the proxy server compares the sequence of characters of the destination URL in the access request with the sequences of characters of the access-prohibited (or access-allowed) URLs from the ACL, and thereby determines whether access should be allowed or prohibited for the access request. If access is permitted, the proxy server forwards (transfers) the access request to the Web server indicated by the destination URL. The Web server receiving the forwarded access request responds with data to the proxy server. The proxy server forwards the received response data to the client that made the access request, and ends the session. However, if access was not permitted as a result of the comparison with the ACL, the proxy server returns an access prohibition message to the client without forwarding the access request to the Web server. The session then ends.
Consider now a specific example using IBM Tivoli Access Manager product at the proxy server where the destination URL “http://www.ibm.com/CustomApp?confidential” is sent from the client to proxy server via the external network. In this case, because the URL (“http://www.ibm.com/CustomApp?confidential”) is entered as an access-prohibited URL in the ACL, the proxy server determines that access is not permitted. The access request is not forwarded to the Web server and the client cannot obtain the resource designated by the URL. Consider another specific example using IBM Tivoli Access Manager product at the proxy server where the destination URL “http://www.ibm.com/CustomApp?public” is sent from the client to the proxy server via the external network. In this case, because the URL (“http://www.ibm.com/CustomApp?public”) is not entered as an access-prohibited URL in the ACL, the proxy server determines that access is permitted. The access request is forwarded to the Web server and the client can obtain the resource (e.g., a Web page) existing in the network address location/web server designated by the URL.
An HTTP access request by the client may need to include in the destination URL a character other than single-byte codes. For example, there are double byte alphanumeric characters such as a hiragana or a kanji in Japanese characters and computer-readable binary code. However, sending such an HTTP access request directly to a network is not generally allowed according to the HTTP protocol. Therefore, it is necessary for the client to encode the sequence of non single-byte characters of a destination URL with a suitable encoding method to reduce it to single-byte codes only. Then, the resulting access request can be sent onto the network.
Consider a specific example in which an access request includes a destination URL shown in FIG. 10 containing Japanese characters formed of double-byte codes, and in which UTF-8 is used as an encoding format to reduce it to single-byte codes. In this case, the sequence of characters of the destination URL is encoded into a sequence of characters “http://www.ibm.com/CustomApp?%E4%B8%80%E8%88%AC%E6%96%87%E6%9B%B8” formed only of single codes using UTF-8 to be sent onto the network. The proxy server receives the access request including the encoded destination URL (“http://www.ibm.com/CustomApp?%E4%B8%80%E8%88%AC%E6%96%87%E6%9B%B8”) and decodes the sequence of characters of the destination URL back to double-byte characters. Then, the proxy server compares the decoded character sequence shown in FIG. 10 of the destination URL with the sequences of characters of the access-prohibited URLs obtained by using the ACL, to determine if access is allowed or prohibited. Because the URL shown in FIG. 10 is entered as an access-prohibited URL in the ACL shown as an example in FIG. 6, the proxy server determines that access is not permitted, and does not forward the access request.
There are various encoding formats other than UTF-8, such as Shift-JIS and EUC (Extended Unix® Code). In some cases, the encoded destination URL in an access request sent from the client to the network to access a resource on the Web server varies depending on the encoding format used by the client. Consequently, there is a possibility that use of an encoded URL character sequence to determine whether to allow or prohibit access using the conventional URL-based access control will lead to generation of a security hole if the wrong decoding algorithm is used. For example, in a case where encoding of an access request using an access-prohibited URL as a destination URL is performed by Shift-JIS in the browser, there is a possibility of erroneous determination of access-allowed/access-prohibited in the proxy by decoding using EUC algorithm. In such a case, the access request may be allowed when it should be prohibited. The problem worsens when different encoding formats are permitted for a sequence of characters having a destination URL in an HTTP request including a double-byte code (a Japanese character or the like). For example, in the case of invoking a resource existing at the URL shown in FIG. 10, Microsoft Internet Information Server® (IIS) program accepts either a URL expressed by the encoding format UTF-8 or a URL expressed by the encoding format Shift-JIS with respect to the portion of the URL sequence shown in FIG. 11.
Published Unexamined Patent Application No. 2000-33085 (Patent Document 1) discloses an information transmitting and receiving system 30 having a security management section 33 which checks whether access to a designated URL is permitted. In Published Unexamined Patent Application No. 2000-33085, however, only single-byte codes are included in a URL character sequence.
Published Unexamined Patent Application No. 2000-20444 (Patent Document 2) discloses a function-expanded apparatus enabling inclusion of an arbitrary sequence of characters (a sequence of kanji, hiragana, and/or katakana characters, symbols or the like) in URL. In Published Unexamined Patent Application No. 2000-20444, however, description is made only of improving the expression of a URL character sequence by enabling inclusion of arbitrary sequence of characters. No mention is made of access control with respect to a URL containing a kanji character or the like.
An object of the present invention is to provide secure access control in a proxy server for access requests which include an encoded sequence of characters as a destination address location.
A more specific object of the present invention is to provide secure access control in a proxy server for access requests which include a URL containing a character other than single-byte codes as a destination URL.